<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
	<head>
		<title>Known Issues</title>
		<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
		<meta content="http://schemas.microsoft.com/intellisense/ie5" name="vs_targetSchema">
		<LINK href="css/ndoc.css" type="text/css" rel="stylesheet" name="ndocstyle">
		<script src="script/ndoc.js"></script>
	</head>
	<body class="dtBODY" id="bodyID" onload="InitTitle()">
		<div id="nstext">
			<h3 class="dtH3">Known Issues and Limitations in NDoc 1.3</h3>
			<table class="dtTABLE" id="Table2" style="WIDTH: 94%" cellSpacing="0">
				<thead>
					<tr vAlign="top">
						<th width="33%">
							Issue</th>
						<th width="67%">
							Description</th></tr>
				</thead>
				<tr vAlign="top">
					<td><p>Very long type names</p>
					</td>
					<td>
						<p>NDoc creates an HTML file on your hard drive for each topic it generates. 
							Currently the name of this file is derived directly from the full name of the 
							type or member being documented. If the total number of characters in an item's 
							full name (namespace + type + member name) exceed the value of <b>_MAX_FNAME</b>
							(256 characters), NDoc will fail because it attempts to create a file with a 
							name that is longer than the file system supports. In addition, the fully 
							qualified path to a file cannot exceed <STRONG>_MAX_PATH</STRONG> (260 
							characters).</p>
						<p>For fully qualified names under about 200 characters, the work around for this 
							issue is to set the <STRONG>OutputDirectory</STRONG> setting to a location as 
							close to the root of a volume as possible. This will reduce the likelyhood of the 
							full path to the html files exceeding 260 characters.</p>
						<P>There is no work around for names that exceed these lengths.</P>
						<p>We will address this issue in a future version of NDoc.</p>
					</td>
				</tr>
				<TR>
					<TD><p>Case-sensitivity</p></TD>
					<TD>
						<P>When the MSDN and JavaDoc documenters create files, problems can arise when 
							there are Types or Members that differ only by case.</P>
						<P>It is possible to work around this problem by avoiding types and members that 
							differ only by case; for example use public property <STRONG>Thing</STRONG> and 
							private field <STRONG>_thing</STRONG>, instead of <STRONG>Thing</STRONG> and <STRONG>
								thing</STRONG>.</P>
						<P>We will address this issue in a future version of NDoc.</P>
					</TD>
				</TR>
				<TR>
					<TD><p>StrongNameIdentityPermissionAttribute</p></TD>
					<TD>
						Assemblies decorated with the <b>StrongNameIdentityPermission</b> attribute can 
						only be called by other assemblies that are marked with the specified key. NDoc 
						will fail when it attempts to document an assembly compiled with this 
						attribute.<p>To work around this issue, conditionally compile a version of the 
							assembly that does not include the StrongNameIdentityPermission attribute.</p>
					</TD>
				</TR>
				<TR>
					<TD><p>Compact Framework incompatibilities</p></TD>
					<TD>
						<P>When an assembly compiled to run on the .NET Compact Framework is added to an 
							NDoc project, the GUI may throw an exception, especially if the assembly 
							references Microsoft.WindowsCE.Forms or SqlServerCe.
						</P>
						<P>There is no work around for this issue.</P>
						<P>We will address this issue in a future version of NDoc.</P>
					</TD>
				</TR>
				<TR>
					<TD><p>Localisation</p></TD>
					<TD>
						<p>NDoc does not currently support Localisation of headings and predefined text.</p>
						<p>We *may* address this issue in a future version of NDoc.</p>
					</TD>
				</TR>
			</table>
		</div>
	</body>
</html>
